Developing a large scale software systems has often consumed an inordinate amount of time and effort and has proven to be extremely difficult to effectively monitor and control.
Often, a large scale software system, will contain a number of software subsystems each of which is formed of modules. Each module provides a specific low level function. Various modules are integrated together at a higher functional level into a particular subsystem in order to provide a specific task. All the subsystems are integrated together at an even higher functional level, through an appropriate program, to allow data to pass between the subsystems as needed and thereby provide the full functionality required of the entire system. The current status of each subsystem must be known at all times in order to effectively monitor and control the development of the entire system.
An illustrative example of a large software system that finds widespread use by the Bell Operating Companies (BOCs) is the TIRKS System (TIRKS is a trademark of Bell Communications Research, Inc.).
At its inception during 1972-1973, the TIRKS system began as a relatively small system. An early version of the TIRKS system was written in assembler language for the IBM Model 360/370 computer. At that time, the TIRKS system had only 5 subsystems. Its function was simply to track inter-office circuit orders and inventory inter-office equipment and facilities. To exploit advances in computer and communication technology and thereby enhance the capabilities of the TIRKS system, new subsystems and modules have been added. Currently, the TIRKS system contains approximately 50 different subsystems that together utilize approximately 10 million lines of source code spread across approximately 23,000 different modules. These subsystems now provide a number of diverse functions; such as marketing (accepting customer orders for inter-office network services), provisioning (equipment and facility inventorying, order tracking; and inter-office equipment and facility assignment), operations (establishing actual inter-office connections, and monitoring and testing of the interoffice network).
Now, with this overview of a large scale software system, such as the TIRKS system, in mind, each subsystem that forms a part of the software system has a "life cycle" comprised of several distinct phases. The activities that occur at each phase vary depending upon whether the software system is entirely new or is on-going and evolving, such as the TIRKS system. Simplistically speaking, the first activity for a new system is the "conceptualization" phase which occurs at the beginning of the entire development effort. During this phase, one or more project goals are first defined and then various alternative solutions aimed at achieving these goals are proposed. Thereafter, during the "design" phase, the chosen solution is parsed into viable subsystems and constituent modules, and all the subsystems and modules are designed. Subsequently, during the "implementation" phase, all the subsystems and accompanying modules are coded. Once coding has been completed, each module is then "tested" and thereafter integrated into its corresponding subsystem which is itself then tested. The entire software system then undergoes system testing--usually first in a development environment and later in a user environment. After system testing has been completed, the entire software system enters the "production" phase in which it is provided to a user for actual use. Frequently, a subsystem will contain an unforeseen error, i.e. a "bug", which will only be discovered during actual use. Each "bug" is eliminated by first detecting its cause, and then conceptualizing and designing a solution followed by suitably modifying the appropriate subsystem. Thereafter, the modified subsystem is tested to ascertain that it operates properly before it is then put into actual use. Moreover, as computing technology changes, one or more subsystems, and possibly the entire software system, may be re-designed and recoded to take advantage of intervening advances that have occurred since the time the entire system was first implemented.
For an on-going software system, such as the TIRKS system, the conceptualization phase is driven by both user requirements and technological advances. First, maintenance requests (MRs) and/or user requested enhancements (hereinafter collectively referred to as user requests) for each subsystem are determined. Each MR documents an improperly performing function that exists in a current subsystem and serves as a request to ascertain the cause of the malfunction and appropriately correct the subsystem. Enhancements, by contrast, are desired features that do not currently exist in a subsystem. Once the user requests have been obtained, their implementation is decided. In certain instances, an existing subsystem can be changed to satisfy these user requests and, in other instances, new subsystems must be completely designed. The conceptualization phase phase also involves determining what additional subsystems must be added to the TIRKS system in order for it to exploit advances in computing and/or communication technology. Each software developer assigned to the TIRKS system is responsible for a particular "unit" of the system. This unit may comprise one or more modules or an entire subsystem. During the "design" phase, each developer designs the software to provide the requested modifications and enhancements applicable to his unit. This unit of software is then coded by each developer during the subsequent "implementation" phase. The "testing" phase consists of three separate activities: unit testing, integration testing and system testing. Initially, each software developer independently tests his own unit of work. Specifically, each developer writes a test routine which provides simulated inputs to the software unit he is testing and then records the results. Once this has occurred, the tested subsystems are integrated together and tested as a whole to ensure that software interfaces properly pass data between the individual subsystems. Thereafter, the entire system is tested to ensure that enhancements and modifications function properly. After the conceptualization, design and testing phases have been completed, a particular release of the TIRKS system emerges. At that point, the release is provided to each BOC which performs acceptance testing in an isolated environment prior to placing the release into actual commercial use. Even after all this testing has been performed, problems may still arise in the field necessitating additional MRs and further iterations through conceptualization, design and testing phases to remedy these remaining problems.
During 1985, approximately 320 releases of the TIRKS system were delivered to all the BOCs. Each release contained between 1 module for an emergency release--a release designed to correct one specific malfunction occurring in that module--to a major release containing as many as 2,000 modules. Generally, about 30 releases are being simultaneously developed at any given time.
Because of the enormity of the software development effort required to maintain and support the TIRKS system and the large number of subsystems involved, a management information (MIS) system is needed to effectively monitor the TIRKS system; and, specifically, to efficiently allocate available development resources, as the need arises, for developing new subsystems and for properly maintaining all the existing subsystems in a timely manner. Specifically, all the users prioritize their MRs and specify the order in which these MRs are to be handled. To ensure that all the MRs are being handled in a manner consistent with BOC requirements, the MIS system must constantly monitor the software development life cycle of every subsystem in each release of the TIRKS system that is in use and provide current information to management. This information permits management to effectively re-allocate resources (development personnel and hardware facilities), if necessary, to assure that these requirements will be met.
One such MIS system used a variety of specialized software support systems to provide specific information relating to one or more phases of the life cycle of each subsystem that formed the entire software system. These support systems included: planning systems which set milestones for each phase of the development efforts and estimated necessary development resources, scheduling systems which allocated and scheduled specific resources such as programmers, administration systems which tracked budgetary and financial information, marketing systems which logged user requests, systems that tracked source code for each subsystem of each release under development, systems that monitored delivered source code, and systems that prioritized action items and programming responsibilities. Other specialized support systems were used to monitor software test environments for development and integration testing.
Each support system produced some form of report. Although reported data was available for each phase of the life cycle for every subsystem, the data produced by all the support systems could not be easily integrated together to provide the information required by management. For example, assume a manager desired to correlate the trend in new and changed lines of code produced during the development phase with the faults found in the system test phase. This task would be difficult because the data in the support systems is spread across several databases used by these systems. Moreover, these support systems only produced data that reflected current activity and hence failed to provide the most useful management information for detecting bottlenecks in the development process; namely, historical trends, and comparisons between past and present development activities.
In spite of these deficiencies of such MIS systems, managers could obtain useful status information for relatively small software systems under development by separately consulting with each developer. The manager would then assimilate all the information presented from every developer to obtain an accurate assessment of the status of the entire software system. Unfortunately, as the number of developers increased, this management approach became increasingly impractical due to time constraints of the manager and each developer. As a result, an "information crisis" occurred as the size of the software system being developed increased--i.e. as the software system continued growing, managers became increasingly unable to obtain useful status information. Generally, at this point, someone in the development organization recognized the wealth of information provided by the support systems. As a reaction to this crisis, an MIS system was often put in place to automatically extract particular information from all the data provided by all the support systems and provide the extracted results to management in the form of reports.
There are several drawbacks inherent in a reactive MIS system particularly when used to monitor and control the development activities of a large scale ongoing software system, such as the TIRKS system. First, such an MIS system is very inflexible. It only provides the specific information that satisfies a manager's particular needs occurring during an information crisis. As such, a reactive MIS system disadvantageously ignores a development organization's long term information needs. This, in turn, ensures that future information crises will occur and another reactive MIS system will be put in place each time management needs change and managers request different information. Second, a reactive MIS system provides the same reports to all managers. A large scale software system, such as the TIRKS system, with 50 subsystems generally involves many managers. Generally, a manager assigned to the TIRKS system has responsibility over several subsystems. The information needs of one manager are generally not the same as those of another. Hence, MIS systems geared to satisfy the needs of one manager do not satisfy the needs of other managers. As such, reactive MIS systems hide relevant information from some managers and thereby prevent these managers from focusing on their areas of responsibility. Third, the extracted information is geared to that produced by each software support system. Since the support systems only produced data regarding current development activities, reactive MIS systems also failed to provide historical trend information--information essential in managing and controlling large scale software development efforts.
Furthermore, reactive MIS systems disadvantageously inject a large degree of uncertainty into the development schedule of a large software system. First, MIS systems known in the art were often extremely slow to respond and hence presented "stale" information to management. Additionally, the initial estimate of time required to develop a fully functional subsystem was often inaccurate. Thus, with a lack of current information in a delay prone MIS environment, managers were often unable to accurately estimate and schedule the resources required to handle each user request. Second, since a reactive MIS system hid information from managers, many managers were unable to probe deep into the development efforts to investigate and uncover actual causes of delay. Thus, these managers were unable to quickly spot bottlenecks in their area of the development process, and quickly and dynamically re-allocate their available resources in a decisive manner to eliminate these bottlenecks. Ultimately, this uncertainty increased the expense of developing a large scale software system.
For those reasons, MIS systems known in the art can not be used to effectively monitor and control the development of a large scale software system.
Therefore, a need exists in the art for a computer based management support system for monitoring and controlling on-going development efforts of a large scale software system, and, more specifically, for providing whatever information is required by each manager to effectively control and predict the software life cycle of each software subsystem under development. This system should be capable of easily integrating available data from a variety of specialized computer based support systems. As an aid in monitoring present development efforts and in planning future efforts, this system also should preserve historical development information and provide summary and trend data based upon historical performance of past software development efforts. Furthermore, this system should provide a flexible query facility that enables each manager to independently query the integrated data in order to extract information of interest to that manager. This system should also provide an analysis facility which permits the manager to analyze query results in any desired fashion. Lastly, this system should permit managers to verify the integrated data by providing access to each specialized support system.